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Objectives 


Inform  the  reader  of 

•  how  effective  data,  metrics,  analytics  and 
management  can  make  the  Observe-Orient-Decide- 
Act  (OODA)  loop  faster  and  more  effective 

•  how  a  faster  and  effective  OODA  loop  can  make 
government  cybersecurity  posture  more  adaptive  and 
resilient 

•  how  the  OODA  loop  differs  between  cybersecurity 
governance  and  cybersecurity  operations 

•  how  to  achieve  positive  cybersecurity  governance 
effects  within  the  OODA  framework 
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The  OODA  Loop 

An  Introduction 
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Comparison  of  OODA  to  other 
Frameworks 


OODA 
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NIST  SP  800-39 
Risk 
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‘Source:  NIST  SP  800-39.  According  to  NIST  SP  800-39,  the  Risk-Management  Process  is  not  a  sequential  process  like  the  OODA  Loop  or  the 
Shewhart  Cycle.  All  components  can  receive  input  and  send  output  directly  to  all  other  components. 

“Source:  Walton  (1988) 
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Why  the  OODA  Loop 


Federal  government  at  inherent  cybersecurity  disadvantage  in 
comparison  to  threat  actors  due  to  size  and  structural 
constraints 

Improved  and  faster  OODA  can  leverage  Federal  government’s 
inherent  advantages: 

•  Economies  of  scale 

•  Opportunities  for  information  sharing 

•  Access  to  law  enforcement  channels 

•  Goals: 

•  Reduce  threat  advantage 

•  Decrease  Federal  government’s  enterprise  wide  risk  surface  area 

•  Increase  cybersecurity  governance  efficiency 

•  Increase  threat  actors’  work  factor  across  the  enterprise 

Note:  The  Act  phase  of  the  OODA  loop  does  not  have  to  lead  to 

Dosture-affectinq  change.  It  mav  lead  to  another,  more  refined 
OODA  loop. 
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Cybersecurity  Governance 


Software  Engineering  Institute  (larne^it^  iV  lei  Ion  L  niwi-Hity 


7 


Comparison  of  Operations  and 
Governance 


Scope 

Individual 

Multiple  networks. 

networks,  systems, 

systems,  user 

users. 

bases. 

organizations 

organizations 

Timescale 

Immediate  to  6 
months 

6  to  36  months* 

Level  of 

Transactional 

Trends, 

Abstraction 

aggregations 

Management 

Direct  interaction 

Context  setting 

Impact 

*Although  the  maximum  technology-related  decision  is  limited  to  approximately  three  years  due  to 
rate  of  technological  change,  government  organizations  must  program  their  expected  budget 
needs  five  years  in  advance.  In  addition,  DoD  is  legislatively  mandated  to  formulate  strategy  and 
priorities  through  the  Quadrennial  Defense  Review  process. 
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Facets  of  Cybersecurity  Governance 


lii 

/j'- 


'I* 


Enterprise  Risk 
Management 


Legai,  Reguiations, 
Poiicy,  Orders, 
Investigations  & 
Compiiance 


Organizationai 
Training 
&  Awareness 


Organizationai 
Structure  Management 


Enterprise 

Portfoiio 

Management 


Financial  Resource 
Management 


Enterprise  Acquisition 
&  Materiel  Management 


i 


Human  Resources  Management 
&  Leader  Development 


/\ 

/\ 

V 

V 

Y 

V 

Warfighter 

Business 

DoD  portion  of  Intelligence 

Enterprise  Information  Environment 

Mission  Area 

Mission  Area 

Mission  Area 

Mission  Area 
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Using  Data  to  Support  Both 
Gpyernance & Operatipns Cycles 
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Enabling  Data-Driven 
Decision  Making 

A  faster,  more  effective  OODA  Loop 
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Measure  to  Support  Action 


Observe 

•Data  Collection 
•Data  Analysis 


Identify 
requirements 
from  mandates, 
doctrine, 
strategy 


Group 

requirements 
into  categories 


Develop  one  or 
more  goals  for 
each  category 


Develop  one  or 
more  questions 
that,  if 

answered,  help 
determine  if  the 
goal  is  met. 


Identify  the 
information 
requirements  to 
answer  the 
question 


Identify  the 
metrics  that  will 
measure  the 
indicator  to 
answer  the 
question 

Use  new  metrics 
to  mature 
current  metrics 
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Collecting  Situational  Awareness 
Data  and  Information 


Observe 

•Data  Collection 
•Data  Analysis 


Unstructured  Data 
Machine  Learning 
Text  Analysis 
Trend  Anaiysis 
Correiation 


Automated  vulnerability  sensor 
information 

•Hardware  &  Software 


•Behavioral  Observables  (Insider  Threat) 


Threat  Information 

•Threat  Actor  Analysis 
•Prevailing  Attack  Patterns 

e  e  e  e  e 

Management  Information 

•Budget  Information 
•Demographic  Information 
•Legal  &  Administrative  Investigation 
Statuses 

•Mission  Impact  Analysis 

9  9  9  9  9  9 


Qualitative  Assessment 

•  Inspections/Assessments 

•  Professional  Sentiments  Analysis 

9  9  9  9  9  9 
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■  Orient 


Sources  of  Constraints  and 
Mandates 


•strategy  &  Policies 
•Norms  &  Practices 


k.  A 


Executive 


Authority 

Appropriation 


Case  iaw  (if  appiicabie) 


Executive  Order 
OMB  Mandate 
FiPS 

Reguiations/Miiitary  Orders 
Doctrine  &  Strategy 
Recommendations/Guides 
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Orient 


Government  Strategy  Landscape 


•strategy  &  Policies 
•Norms  &  Practices 


Nested  Overarching  Strategy 


Cyber-Related 

Strategy 


Critical 

Infrastructure 

Strategy 


National  Security  Strategy  (POTUS) 

L _ 

National  Defense  Strategy  (SECDEF) 

L - j 
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Plans 

L  i 

Service 

Component 

Strategy 

il 

Combatant  Unified 

Command  Command 

Strategy  Strategy 

i _ ! 

FNR 

Strategic  Plan 

Quadrennial 

Defense 

Review 

(SECDEF) 


HSPD-7 
National 
Strategy  to 
Secure 
Cyberspace 


^ 

Digital 

Government 

Strategy 

► 

I 

National  1 

Pybersecurity 
Initiative 


Quadrennial 

Homeland 

Security 

Review 

(SECDHS) 


Blueprint  for 
a  Secure 
Cyber 
Future 
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Use  Behavioral  Models  to  Target 
Stakeholder  Information  Needs 


*  Orient 

•strategy  &  Policies 
•Norms  &  Practices 


v: 


information 


Executives: 

•  Elected  leaders, 
appointees,  GOs,  FOs, 
SESs 

•  Target  data  with  eye 
toward  organizational 
mission  and  stakeholders 

Middle  Management: 

•  Staff  officers, 
analysts 

•  Target  data  with  eye 
toward  routines, 
procedures 


Source:  Allison,  G.  T.,  &  Zelikow,  P.  (1999).  Essence  of  Decision:  Expiaining  the  Cuban  Missiie  Crisis  (2nd  ed.)  (Kindle  Edition).  New  York: 
Longman. 
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Key  Planning  &  Decision-Making  *CoA  Development 

^  •Planning 

Factors . 

•  Theory  or  hypothesis? 

•  Hypothesis  -  analyze  through  subsequent  OODA  loop 

•  Theory  -  develop  action  plan  to  effect  change 

•  Identify  and  prioritize  governance-level  risks;  identify  metric- 
supported  thresholds  of  acceptability  and  unacceptability 

Support  solutions.  Go  beyond  “name  and  shame”.  Use  metrics 
to  identify  key  trends  and  corrective  governance-level  actions 

Tie  metrics  to  a  resulting  set  of  possible  risk  management 
outcomes 

Identify  enablers  such  as  SMEs,  funding,  contract  vehicles 

•  Identify  organizations  that  exceed  expectations  in  certain  areas 
and  their  lessons  learned 

Identify  what  expected  changes  in  metric  values  should  be  and 
how  to  avoid  bias/gaming 

•  Prioritize  and  identify  metric  thresholds  where  costs  will  exceed 
benefits. 
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Act 


Leveraging  Enablers  to  Achieve 
Desired  Effects 


•Execution 

•Follow-Up 


CERT 
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Act 


Success  at  the  Point  of 
Execution 


•Execution 

•Follow-Up 


•  Leverage  enablers  at  the  proper  organizational  level; 
avoid  the  “3,000-mile  screwdriver” 

•  Governance  sets  the  direction  through  governance 
facets.  Operations  executes  through  disciplined 
project  management 

•  Avoid  numerous,  rapid  changes  that  cause  enterprise 
turbulence 

•  Tie  actions  to  expected  outcomes  and  expected 
timeframes:  socialize  and  communicate  expectations 

•  Set  decision  points  to  check  progress  against 
expectations 

•  Build  knowledge  base  to  make  for  faster  and  more 
effective  OODA  loop 
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How  to  Implement 


serve 


•  Inventory  on-hand  data 

•  Inventory  metrics 

•  Develop  data  fusion  capabilities 


Orient 

Decide 

Act 


W 


Refine  metrics  based  on  constraints,  mandates,  threat  patterns 
Define  stakeholders  based  on  behavioral  models 
Develop  quantitative  and  qualitative  analysis  engines 
Develop  visualization  capabilities 


•  Inventory  enablers  and  their  capabilities 

•  Identify  desired  outcomes  for  metrics  (i.e.  thresholds) 

•  Develop  decision  support  TTPs 

•  Develop  decision-support  systems 


•  Develop  knowledge  base 

•  Simulate  and  practice  new  decision-making  TTPs 

•  Develop  and  refine  process  control  mechanisms 

•  Develop,  refine  and  leverage  communications  channels 
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Outcomes  of  Data  Driven  Governance 


Faster,  more  accurate 
decision  making 

Better  use  of  resources 

Better  enterprise 
cohesion  and 
synchronization 

Data-driven  outcomes 

Improved  information 
sharing 

Adaptable  to  change 
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Questions 
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Back-Up  Slides 
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The  OODA  Loop 


•  Mental  model  for 
conceptualizing  how 
individuals,  organizations 
make  decisions 

•  Origins  in  the  DoD;  used 
in  legal  and  business 
communities 

•  Describes  the  ability  to 
acquire,  process  and  act 
up  on  information  with 
respect  that  that  of  one’s 
adversary 
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Orient 


•Execution 

•Follow-Up 


•Strategy  &  Policies 
•Norms  &  Practices 


Decide 
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•Planning 
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The  OODA  Loop 


•  Observe:  Gathering  sensory  inputs  from  the 
environment  of  the  observer 

•  Orient: 

•  Make  sense  of  the  observational  data  to  create  a  mental 
picture  of  the  situational  reality 

•  Used  to  make  sense  of  the  input  data  in  light  of  what  is 
“known” 

•  Provides  the  basis  for  decisions 

•  Decide:  Deciding  on  a  course  of  action  based  on 
Orientation 

•  Act:  Bringing  decision  to  fruition  at  point  of  execution. 


Source:  Angerman  (2004) 
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